Currently, the spread of malicious software is increasing every day, as does the damage caused by such software to users' personal computers. The existing methods for protecting personal computers and computers in a corporate network are designed to discover both known and unknown threats. The methods for protection from known threats (for example, viruses, worms, Trojans, and general vulnerabilities) are usually based on signature scanning, which uses code templates obtained from known malicious programs for subsequent verification of objects. In addition, related approaches for protection from known threats include: the “white lists” technology, which uses templates of known trusted programs; the “black lists” technology; systems for verification of check sums, of metadata, etc. However, the rate with which new malicious software appears is constantly rising, which leads to an ever-increasing role for proactive protection technologies that work to the benefit of users. The methods for proactive protection generally involve a code emulator. The emulator breaks the program's byte code down to commands and runs each command in a virtual copy of the computer. This allows the protection tool to monitor the program's behavior without endangering the PC's operating system and the user's data.
Today, such emulators can also contain an analytical module, which collects information about the analyzed object, conducts research, uses such research to make conclusions on the potential malicious nature of an object, and puts together detection rules. Usually, an emulator with an analytical module performs deep analysis using rules for the detection of unknown threats. These rules were previously created by antivirus service providers. When examining applications, an emulator can use various ratings. During the emulation of applications for subsequent analysis/research, a log of events having occurred is formed, which contains both usual events associated with programs known to be safe, as well as suspicious events associated with other, unknown, programs. Based on the analysis of such an event log, during which the detection rules of events and rules of calculating security ratings are used, a final verdict is issued on the examined application indicating its harmfulness.
Today, there are various methods for filtering event logs. Usually, filtration is used in order to obtain required data from the log, depending on required criteria. However, known technologies do not effectively solve one of the main log analysis problems, namely, the fact that the analysis is very time-consuming because the event log oftentimes has grown to a colossal size during emulation, which can amount to be on the order of a million lines. Another problem has to do with making a decision during analyzing of such logs—the events which are significant for issuing a verdict become diluted among the huge number of insignificant ones.
An insignificant event is an event which is not important from the point of view of behavior during maliciousness risk analysis, because such events will happen during execution of either safe or malicious software. Consequently, insignificant events do not allow accurate determination of whether a particular item of software is dangerous. Typical examples of insignificant events are events which will be created during the execution of software written in the Delphi programming language. The execution of such applications can create many typical events found in any program created using Delphi. For example, these can include events that occur in connection with running code that was added during the compilation of the application, e.g., <<startup code>>.
One challenge in the development of systems for filtering events is the fact that the execution of training rules (whether newly-created, or adapted from previous detection rules for events having occurred) involves the risk of creating a rule that is typical for some legitimate program application, i.e. that will cause false activation of the rule. Examples of events from which rule may be falsely triggered, are those that typically occur during the execution of an application that was compressed, or encrypted, using specialized security software. A typical example of program application is a protector from probing (for example, OSProtector), which can perform many various operations in order to protect the program application from hacking, but this is not an indication of legitimacy or maliciousness of the application, because any application secured by this kind of protector will have such behavior.
In view of the above, a solution is needed to improve event log filtering specifically for malware analysis that can be performed locally on a distributed plurality of user computer systems.